I suspected this is just one of a class of bugs:

=========== CLAUDE ===========

Fix for #26231 — undercompilation when a
case class field type changes and a downstream file pattern-matches on it.

Summary of the change

Scala 3 generates def unapply(x: C): C = x for case classes, so the unapply signature
never changes when field types change. PatternMatcher (which runs after
ExtractDependencies) lowers case C(x, y) to calls to the product selectors _1, _2, …,
so those calls are never in the tree that Zinc dependency extraction sees. The fix adds a
case UnApply to recordTree in compiler/src/dotty/tools/dotc/sbt/ExtractDependencies.scala
that records each product selector of the unapply result type as a member-reference used name.

Verdict

✅ Correct for the targeted scenario.

• The original bug reproduces end-to-end on released Scala 3.7.3:
  NoSuchMethodError: 'java.lang.String C._2()' at runtime after changing a field type,
  with no recompilation of the matching file. Recording _1.._N makes the selector's
  name hash change, which invalidates the dependent file.
• Field removal is also covered: the _N name disappears, which Zinc treats as a change.
• The new case is additive: traverse calls recordTree per node and traverses children
  independently, so fun and sub-patterns are still visited. Inlined code also benefits via
  the recordTree call in transform/Inlining.scala.
• Non-product result types (Option[...], Boolean, custom wrappers) degrade harmlessly:
  productSelectors returns Nil.

Nits

• case UnApply(fun, implicits, patterns) — implicits and patterns are unused; use
  UnApply(fun, _, _).
• The comment references Customer2, a leftover from the issue repro.
• Import reshuffling / blank-line churn at the top of the file is unrelated to the fix.
• Known mild overapproximation: a file matching tuples records _1/_2 and can be
  spuriously invalidated when an unrelated dependency's _2 changes. Inherent to
  simple-name hashing; acceptable.
• The sbt-bridge test was not run locally (needs a full compiler build) — confirm
  sbt-bridge/testOnly xsbt.ExtractAPISpecification is green in CI.

Related bugs found (all confirmed empirically on Scala 3.7.3, not covered by this fix)

Repro harness: one sbt module, upstream
case class C(a: String, b: String); object A { val c = C("first", "second") },
downstream file pattern-matching A.c.

1. Named pattern + field rename → stale success.
   Downstream case C(b = bv); renaming b upstream should produce
   No element named 'b' is defined in selector type C, but the file is not recompiled.
   Named patterns are desugared to positional form in Desugar.adaptPatternArgs using
   caseAccessors; the field name is never recorded as a used name.

2. Named pattern + reordering same-typed fields → silently extracts the wrong field.
   Incremental run printed b=second; clean build prints b=first. No crash, no error,
   wrong data — arguably worse than Undercompilation in all scala3/sbt versions leading to NoSuchMethodError on pattern matching #26231. Nothing hashable changes: unapply is
   (C): C and _1/_2 are both String before and after.

3. Adding a field → stale success.
   Positional case C(av, bv) should fail with "Wrong number of argument patterns" after a
   third field is added, but is not invalidated: _1/_2 are unchanged and _3 is a new
   name nobody used.

4. Name-based extractors → runtime crash.
   def unapply(x: String): W where W has isEmpty/get: changing get's result type
   gives NoSuchMethodError: 'java.lang.String W.get()' without recompilation.
   Same root cause — PatternMatcher emits the isEmpty/get calls after
   ExtractDependencies runs.

Repro pitfall worth documenting

Any downstream file using string interpolation appears to be invalidated correctly —
but only by accident: s"..." desugars to StringContext.apply, and Zinc hashes used
names by simple name, so any case-class signature change (which changes C.apply)
collides and invalidates the file. End-to-end repros must avoid apply entirely.
The branch's sbt-bridge test asserts on used names directly and is immune.

Suggested follow-ups

NamedArg nodes survive into the typed UnApply tree (-Xprint:typer shows
case C(_, b = bv @ _)), so ExtractDependencies can detect named patterns:

• When a sub-pattern is a NamedArg, record the primary constructor (C;init;) or
  companion apply as a used name. Verified via Zinc debug logs that its hash changes on
  field rename, reorder, retype, and arity change → fixes bugs 1 and 2.
• Recording <init> for all case-class unapplies would also fix bug 3 (arity increase),
  at the cost of overcompiling positional matches when constructor params are merely renamed.
• For non-product unapply result types, record isEmpty/get (name-based extractor
  protocol), and the lengthCompare/apply/drop family for unapplySeq → fixes bug 4.